How to avoid "saying nothing"
元ネタ
What a great way to say nothing.
(なんて意味のない発言なんだ)
Unless you follow up your “it depends” or “it’s all about trade-offs” with an actual disposition of WHAT it depends on or HOW to weigh those trade-offs, you’re saying less than nothing. It’s an intellectual pause button.
(「それは状況による」とか、「すべてはトレードオフだ」といったことについて、じゃあ何に依っているのか、あるいはどうやってそのトレードオフの釣り合いを取っているかの実態を追求しない限り、その発言には何の意味もない。それは知能の停止ボタンみたいなものだ。)
DHH の意見は個人的に同意できないことが多いが、このスタンスだけは明確に素晴らしいと思っている。
というのも私は技術記事やスライドの最後に「要はバランス」「銀の弾丸はない」といったフレーズを見ると本当に苦虫を噛み潰したような表情になるからだ。
これらのフレーズは要するに、まとめを書くのを諦めたときのフレーズであり、そもそもその人の意見とは呼べず、せっかく良い内容であっても「じゃぁ今まで書いてきたことは何だったんだよ」といった台無しの読後感を残す効果を持つからだ(最近「学習コスト」という単語もこのラインナップに入りつつある)。
本来こういうフレーズが役に立つのは、たとえば議論があまりにも白熱したせいで誰でも知っているようなことを忘れた人を前にした時、その人をたしなめたり戒めたりするときとかだろう(この記事がもしそうなっていたら戒めて欲しい)。
簡単に言うと困った人間に対してたまに使うからこそ価値があるもので、普通の流れでこんなもの使っていたら人をバカにしていると思われてもしょうがないフレーズである。
(これらのフレーズが謙虚さのアピールとして役に立つケースもあるが、最近はその効果も薄れてしまいデメリットのほうが増えつつある)
なぜこうした回避行動が生じるのかと言うと、それはその人がスライドや技術文書を「情報」を伝えるものだと考えているからだろう。我々はふつう、勉強会では「知見を共有する」と言うが、「情報を共有する」とはあまり言わない。
「情報(information)」と「知見(notion)」は明確に異なり、後者には意見や立場が含まれる(情報にも含まれることはもちろんあるけど今は置いといてくれ)。
「知見」を表明するのを回避する人は「意見」を回避している。「銀の弾丸はない」は今日、そういう回避の姿勢として現れるフレーズとなった。
まぁ「主観的」という言葉を悪い意味で使う人間を見すぎたせいで悪影響を受けたとかだと思う(ちゃんと使えば主観は何も悪くないし、私はそういう人間が嫌いだ)ので、同情の余地はあるんだろうが、そういう症状はちゃんと治したほうが良い。
-----
そういうわけで、この記事では以下、自分が技術記事などを書くにあたってどういう言い方をするとマシになりそうと考えてるかをメモしていく。
------
# Lv 1. 明らかに説明不足なので直すべきケース
❌ React は高い学習コストがある
⭕ React は JSX の記法に慣れが必要な箇所がある。たとえば key や className など…
→ 基本的に「学習コスト」という単語は何も表現していない。
あらゆる技術、ライブラリは学習コストを持つ(類例: 人間には身長と体重がある)ので、そんなことを書くぐらいなら「ここがハマりやすいポイントです」とだけ書くのが良い。
本当に難しいかは読者が判断すればよいし、他と比べてどうかについても具体的な難しいポイントを書かないと始まらないだろう。初心者に寄り添う場合も、あげる例としてより基本的なものを選べば良いはずだ。
もちろん、こういう根拠を一通り説明した後にそのまとめとして学習コストというならあまり問題はない。
--
❌ PWA は銀の弾丸ではない
⭕ PWA は〇〇なチーム、△△なプロダクトには比較的向いているが、そうでないならオススメできない
⭕ PWA は iOS アプリで欲しいはずの ■■ な要件を満たせないのでそういう時はやめておけ
→ 銀の弾丸がこの世にないことは(はてブに頭をやられていない限り)プログラマなら誰でも知っている。これを普通の流れでいうと読者をバカにしているように感じられるだろう。
「最初すごい PWA に期待してたけどやってみたら意外とそうでもなかったわ」という気持ちからアウトプットをしているなら、率直にそれを表現したほうが読み手は得るものが多いはずだ。
批判的な内容を読むのは場合によっては読者の気分を害するかもしれないが、意味のある結論が存在しない文章よりはマシだ。両方揃うと最悪のアウトプットになるので、何かを批判する時こそまとめは妥協してはいけない。
--
❌ Redux を使うべきかは、実装速度とメンテナビリティのトレードオフで決める
⭕ △△ぐらい複雑な画面なら Redux を使ってペイする、それ以下の規模でペイするかは正直怪しいと思っている
ある種のライブラリの複雑性が実装速度に悪い影響を与える、という事自体はもちろんよく起こりうる。
とはいえ、じゃぁ経験則でこういうときに使ったら辛かったですと言ってくんないかなと感じることが多い。ぼかしても良いし、頑張って明確な基準にしなくても良いので。
トレードオフの話をするときに「要はバランス」と言うのが悪いのは、そもそも「バランスが必要な状態」がトレードオフの定義みたいなものだからだ。
それならまだ「それは金の問題です」「これやると追加で数週間かかるがそれを受け入れていいならやります」ぐらいストレートに言ったほうが良い。ふだんチームで起こりがちな後者のやりとりを一般化した知見にするのが重要。